When your release is close, the QA lead says every test passed, and the dashboard is green. But you need to decide if the product is ready, and a green dashboard can’t answer that question. A clear QA process in software testing can. In this guide, you’ll learn each stage and the role responsible for it. Then you’ll see how the team decides that a release is safe.
What Is A QA Process In Software Testing?
The QA process in software testing is the set of stages a team follows to decide if software is good enough to release, from requirements to final approval. QA means quality assurance. The ISTQB glossary describes quality assurance as the part of quality management that gives confidence that the product will meet its quality requirements. So the quality assurance process covers more work than test runs.
QA and QC often appear together, and people mix them. Here’s the difference:
| Quality assurance (QA) | Quality control (QC) | |
|---|---|---|
| Goal | Prevent defects | Find defects |
| Focus | The process | The product |
| Timing | During all stages | When a build is ready |
| Example | A review of the test plan | A test run on a new build |
Testing is part of QC. QA defines the rules for the whole process. You can read more in our article on QA vs QC in detail.
Why The QA Process Matters In 2026
Teams now write a large part of their code with AI tools. This raises the speed of development, and it also raises the number of changes the team needs to check. According to the Stack Overflow 2025 Developer Survey, 84% of developers use or plan to use AI tools. At the same time, 46% of them distrust the accuracy of AI output, and only 33% trust it. The Google DORA 2025 report surveyed nearly 5,000 technology professionals and found that close to 90% use AI at work. The same report shows that software delivery instability continues to grow.
So the software QA process has a new task. It needs to prove that the code works, whoever wrote it: a person or an AI agent. Without a clear process, the team finds defects late. At that point, a fix costs more, and users often see the problem first.
QA Process Steps In Software Testing
Most teams follow the same order of stages. The names change from company to company, and the logic stays the same. Each stage has a responsible role and a clear result.
Requirement Analysis
The team reads the requirements and checks that every requirement is testable. A requirement like the page loads fast is hard to test. A requirement like the page loads in under 2 seconds is easy to test. In Testomat.io, the AI assistant can analyze requirements from Jira and Confluence and suggest test cases for them.
Test Planning
The test plan describes what the team tests and who tests it. It also lists the environments and the end date. The QA lead writes the plan, and the PM approves the scope. If your team uses Jira, you can keep the plan next to the user stories.
Test Design
QA engineers write test cases and checklists for each requirement. A good test case has clear steps and an expected result. For exploratory checks, a short checklist often works better than a detailed test case.
Test Execution: Manual And Automated Tests Together
Many teams run automated tests in CI and manual tests in a separate tool. The results stay in two places, and the QA lead needs to combine them by hand before every release. With a mixed test execution, Testomat.io combines manual and automated tests in a single run and a single report.
Defect Reporting And Retesting
When a test fails, the QA engineer creates a defect with clear steps to reproduce it. The developer fixes the defect, and the QA engineer runs the test again. Regression tests check that the fix didn’t break other features. When many automated tests fail at once, AI failure clusterization groups the failures by root cause, so the team reviews a few groups instead of hundreds of separate errors.
Release Approval
This stage closes the cycle. The QA lead and the PM review the evidence and agree on the decision. The release readiness section below explains what this evidence includes.
All QA Process Steps In A Single Table
This table shows every stage with the responsible role and the exit criterion.
| Stage | Responsible role | Result | Exit criterion |
|---|---|---|---|
| Requirement analysis | QA lead, BA, PM | Testable requirements | Every requirement has acceptance criteria |
| Test planning | QA lead | Test plan | The PM approves the scope and dates |
| Test design | QA engineers | Test cases and checklists | Every requirement has linked tests |
| Test execution | QA engineers, CI | Manual and automated run results | Every planned test has a result |
| Defect reporting and retesting | QA engineers, developers | Defects in Jira, retest results | Critical defects have a fix and a passing retest |
| Release approval | QA lead, PM | Release decision with evidence | The team agrees on the readiness checklist |
Testomat.io AI Support For Each Stage
Testomat.io AI features do part of the routine work at each stage. Here’s where they help:
- Requirement analysis: the AI analyzes requirements from Jira and Confluence.
- Test planning and design: the AI suggests test cases and generates a suite from requirements.
- Test execution: the AI summarizes a finished run on request.
- Defect reporting: AI failure clusterization groups failures by root cause.
- Release approval: the RunGroup Statistic Report summarizes results across a group of runs.
People keep control of the process. The QA lead and the PM make the release decision.
Release Readiness: How To Know The Product Is Ready
A product is ready for release when every in-scope requirement has passing tests and the critical defects have a verified fix. A test run with 100% passed tests doesn’t prove that the product is ready. Maybe the run covered half of the requirements. Maybe several tests are flaky and pass by chance. Many teams use quality gates for this decision. A quality gate is a set of conditions that a build must meet before it moves to the next stage. You can learn more in our guide on how quality gates work. Here’s a simple readiness checklist:
- Coverage: every in-scope requirement has linked tests with a recent result.
- Defects: zero open critical or high-severity defects.
- Stability: the team marks flaky tests and knows which failures are real.
- Gaps: the team reviews tests that never ran in this cycle.
In Testomat.io, the requirements traceability matrix links tests to requirements, so you can see which requirements have coverage. Flaky test analytics and the never-run tests report help with the stability and gap checks.
The DORA research program tracks change failure rate: the share of releases that cause a failure in production. A clear readiness check helps your team keep this number low.
The QA Process For PMs And BAs
PMs and BAs need answers in simple words: what the team tested and what the risk is. Often they can’t see test results, because every seat in the QA tool costs money. As a result, the PM asks the QA lead for a status update before every release, and the QA lead prepares a report by hand.
Where PMs And BAs Join The QA Process
PMs and BAs join specific stages of the QA process:
- Requirement analysis. The BA writes acceptance criteria for each user story. Clear criteria help QA engineers write clear tests.
- Test planning. The PM approves the scope and the dates, so the team agrees early on what the release includes.
- Defect reporting. The PM sets the priority of defects that affect the release scope.
- Release approval. The PM reviews the evidence together with the QA lead and makes the final decision.
What PMs And BAs Need To See Before A Release
A pass rate alone tells a PM very little about the product. Before a release, a PM usually needs answers to these questions:
- Which user stories have passing tests?
- Which stories have open defects?
- Which tests never ran in this sprint?
- Which risks does the team accept for this release?
The QA process gives these answers if every test has a link to a user story. Then the team can show results per story, in the language of the product.
How Testomat.io Gives PMs And BAs Access To Quality Data
Testomat.io shows quality data to people outside the QA team, in the tools they already use:
- Test results in Jira appear next to the user story. A PM opens a story and sees if its tests passed.
- Sprints coverage for Jira shows test results for the whole sprint, story by story.
- Public read-only test reports show results in real time. People outside the QA team can open them without an account.
- Read-only users access lets stakeholders view the test project without edit rights.
- PDF export helps the QA lead send a run report to a client.
Here’s a typical case. The day before the release, the PM opens the sprint in Jira. Most stories show passing tests, but two stories have failed tests with open defects. The PM moves these two stories to the next release and approves the rest. The decision takes minutes, and the QA lead doesn’t need to prepare a separate report.
Common QA Process Problems And How To Fix Them
Most problems in a QA process repeat from team to team. Here’s what to watch for:
- Requirements without acceptance criteria. The team can’t write clear tests. Fix: add acceptance criteria during requirement analysis, before test design starts.
- Manual and automated results in separate tools. The release decision takes longer. Fix: combine both types of tests in a single run and a single report.
- Late testing. QA starts after development ends, so defects appear close to the release date. Fix: start requirement analysis and test design together with development.
- Flaky tests. The team stops trusting failures. Fix: mark flaky tests and fix the cause in the next sprint.
- Outdated process documents. The QA process document stays in a wiki, and the team rarely updates it. Fix: store tests next to the code. Testomat.io supports version control for manual tests in Git as Markdown files.
Bottom Line
A good QA process in software testing ends with a clear release decision and evidence for it. Each stage has a responsible role and an exit criterion, so the team knows when the next stage can start. The process matters more today because AI tools help teams write code faster, and the number of changes grows with every sprint. A clear process helps the team check these changes and find defects before users see them.
If you want to improve your QA process, start with these steps:
- Add acceptance criteria to every user story before test design starts.
- Link every test to a requirement, so you can see coverage for each story.
- Combine manual and automated results in a single report.
- Agree on a readiness checklist with the PM before the release date.
- Give PMs and BAs direct access to test results, so they see the status without a manual report.
Testomat.io links tests to requirements and shows the results to the whole team. PMs and BAs see them directly in Jira. The QA lead and the PM make the release decision with the same data.
👉 See how Testomat.io shows release readiness to the whole team. Try it for free.
